-
Notifications
You must be signed in to change notification settings - Fork 186
[Win32] Adapt further places to round up when computing control size #2729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Win32] Adapt further places to round up when computing control size #2729
Conversation
4a58a39 to
cc79235
Compare
bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/CoolItem.java
Outdated
Show resolved
Hide resolved
bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/graphics/GC.java
Outdated
Show resolved
Hide resolved
cc79235 to
07523f4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall changes look fine now. I checked for completeness regarding computeSize or ...Trim calls and did not see anything being missed.
Testing for regressions is still missing from my side.
Several places in the computations of preferred sizes of controls used commercial rounding instead of rounding up in pixel/point calculations. This change further adapts additional places to ensure that the calculated size will be large enough and and subsequent point-to-pixel calculation when setting the bounds according the computations does not lead to smaller results.
07523f4 to
dd6ee5a
Compare
akoch-yatta
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not find regressions when testing with it, so this PR is good to go.
Several places in the computations of preferred sizes of controls used commercial rounding instead of rounding up in pixel/point calculations. This change further adapts additional places to ensure that the calculated size will be large enough and and subsequent point-to-pixel calculation when setting the bounds according the computations does not lead to smaller results.
This is a follow up to:
I did not find any visual differences yet, so consider this a unification/cleanup to ensure that every conversion involved in
computeSize()calculations rounds up.